service design proposal: batched sampling - #24
Conversation
| } | ||
|
|
||
| message Samples { | ||
| repeated Sample samples = 1; |
There was a problem hiding this comment.
i am not clear why this is considered to be a good change
the problem with adding this option is now you have to worrry about the size of the batches and i am unclear how this signifcantly improves performance?
There was a problem hiding this comment.
now you have to worrry about the size of the batches
can you elaborate on that? are you talking about server-side or client-side?
and i am unclear how this signifcantly improves performance?
by default1 sending each message implies a write() syscall which is an expensive operation and in the past we've seen bottlenecks in this area. and only 1 write can be active at a time for each stream. We'd like to have an ability to reduce the number of writes in the server code, and, based on our experience, this allows to achieve better performance.
Footnotes
-
this is not neccesarily true for all grpc libraries; e.g. in golang, AFAIR, grpc-go performs a transport-level buffering/batching before doing a write() to the socket. but that's not the case with C/C++ grpc lib for example. ↩
2 participants
Considering that gNPSI is expected to have relatively high messagage rate, and a low avg. message size, our team would like to propose the change that allows performing batching on the server side (instead of having to stream back each individual sample).
In the general case, this will allow implementers to have better control over streaming and should allow to achieve better performance at least in some cases (various grpc library implementations have different ways of working with write() syscalls, YMMV).